-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
syntax: Make parsing of paths whitespace agnostic + some other changes #33041
Conversation
(2, __Unused2, "<__unused2>"); | ||
(3, __Unused3, "<__unused3>"); | ||
(4, __Unused4, "<__unused4>"); | ||
(5, __Unused5, "<__unused5>"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove all of these? And replace special_idents
with "non-strict keywords"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I just wanted to leave some free space so the diff is not messed up on every new contextual keyword, but it's not so important I suppose.
Also, naming is hard, what is the short and obvious name to use instead of special_idents
? weak_keywords
maybe? Also, ""
doesn't even look like a keyword!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I wouldn't even have a name. I'd just put all of them in the same bag, and just auto-generate the STRICT_KEYWORD_{START,END}
from the list, with 'strict
still there.
☔ The latest upstream changes (presumably #32875) made this pull request unmergeable. Please resolve the merge conflicts. |
syntax: Parse import prefixes as paths Fixes rust-lang#10415 r? @eddyb (This partially intersects with rust-lang#33041)
@eddyb |
LGTM, very nice! @nrc @erickt @Manishearth, any objections? |
Should be breaking-batch, rather than being landed directly. But I think we should try to land it soon so it doesn't rot. cc @Manishearth |
LGTM |
We don't have any other breaking-batch changes queued up, but this is large enough that it can be landed directly. Let's wait a few days for the stakeholders to prepare for this, and land it then. (In the meantime, if you have any breaking changes planned, now is the time to make PRs!) |
Left a comment on #31645, feel free to land in a few days |
Please land this simultaneously with #31414 . I'll do it myself in a day or two if both get approved. |
I've pushed one more commit. |
Is this ready to land? (two LGTMs, seems good) Just mention r=me, don't actually tell bors to approve it. |
@Manishearth r=me |
Lift some restrictions on type parameters in paths Sanity check import paths for type parameters
Simplify the macro used for generation of keywords Make `Keyword::ident` private
syntax: Merge PathParsingMode::NoTypesAllowed and PathParsingMode::ImportPrefix syntax: Rename PathParsingMode and its variants to better express their purpose syntax: Remove obsolete error message about 'self lifetime syntax: Remove ALLOW_MODULE_PATHS workaround syntax/resolve: Adjust some error messages resolve: Compare unhygienic (not renamed) names with keywords::Invalid, invalid identifiers may appear to be valid after renaming
@Manishearth |
Paths are mostly parsed without taking whitespaces into account, e.g. `std :: vec :: Vec :: new ()` parses successfully, however, there are some special cases involving keywords `super`, `self` and `Self`. For example, `self::` is considered a path start only if there are no spaces between `self` and `::`. These restrictions probably made sense when `self` and friends weren't keywords, but now they are unnecessary. The first two commits remove this special treatment of whitespaces by removing `token::IdentStyle` entirely and therefore fix rust-lang#14109. This change also affects naked `self` and `super` (which are not tightly followed by `::`, obviously) they can now be parsed as paths, however they are still not resolved correctly in imports (cc @jseyfried, see `compile-fail/use-keyword.rs`), so rust-lang#29036 is not completely fixed. The third commit also makes `super`, `self`, `Self` and `static` keywords nominally (before this they acted as keywords for all purposes) and removes most of remaining \"special idents\". The last commit (before tests) contains some small improvements - some qualified paths with type parameters are parsed correctly, `parse_path` is not used for parsing single identifiers, imports are sanity checked for absence of type parameters - such type parameters can be generated by syntax extensions or by macros when rust-lang#10415 is fixed (~~soon!~~already!). This patch changes some pretty basic things in `libsyntax`, like `token::Token` and the keyword list, so it's a plugin-[breaking-change]. r? @eddyb
Paths are mostly parsed without taking whitespaces into account, e.g.
std :: vec :: Vec :: new ()
parses successfully, however, there are some special cases involving keywordssuper
,self
andSelf
. For example,self::
is considered a path start only if there are no spaces betweenself
and::
. These restrictions probably made sense whenself
and friends weren't keywords, but now they are unnecessary.The first two commits remove this special treatment of whitespaces by removing
token::IdentStyle
entirely and therefore fix #14109.This change also affects naked
self
andsuper
(which are not tightly followed by::
, obviously) they can now be parsed as paths, however they are still not resolved correctly in imports (cc @jseyfried, seecompile-fail/use-keyword.rs
), so #29036 is not completely fixed.The third commit also makes
super
,self
,Self
andstatic
keywords nominally (before this they acted as keywords for all purposes) and removes most of remaining "special idents".The last commit (before tests) contains some small improvements - some qualified paths with type parameters are parsed correctly,
parse_path
is not used for parsing single identifiers, imports are sanity checked for absence of type parameters - such type parameters can be generated by syntax extensions or by macros when #10415 is fixed (~~soon!~~already!).This patch changes some pretty basic things in
libsyntax
, liketoken::Token
and the keyword list, so it's a plugin-[breaking-change].r? @eddyb